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(54) Modifying a cryptographic facility of a data processing system 



(57) A cryptographic facility uses object-oriented techniques to define a hierarchical structure representing cryptographic 
services. Whenever an instance of an object class is created, Fig 5, or destroyed, Fig 6, the instance is automatically 
respectively registered with a list of services supported by the system or de-registered from the list. This facilitates 
modification of the system, e.g. by adding a new service. 

The cryptographic facility is used in communications between applications (14, Fig 1). 
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J pass algjdent and key_sz to 
i Cryptographic_AlgorftrwTu:Cryptographic^Algorithm j 



i set Alg JJsage.confidentiality « True 



j ! Algorithm JJst I = Null Pointer [ 



H register this' aigorithm object as a 
■ confidentiality algorithm with the algorithm list 



return 



Confidential»ty_Algorithm::^Confidentiality_Algorithrn< ) ; 



! Algorithm^List l= Null Pointer 



deregister 'this* aigorithm object as a 
confidentiality algorithm from the aigorithm list 



return 



O 
OD 

rv> 

ro 
oi 

CD 

Ol 

CO 

o 



i/s 




3/5 




Object Class Representation 

Base Class Name 
Base Class 

Pointer to inherited Base Class 



C 



-Class Name 

— 

-) — Inherited Data Member 
^ — Uninitialised Data Member 
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- Initialised Data Member 
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■Inherited Member Function 

- Pure Virtual Member Function 
(interface defined only, no code) 

Member Function (may be virtual) 
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CRYPTOGRAPHIC FACILITY FOR A DATA PROCESSING SYSTEM 



Background of the invention 

This invention relates to -a cryptographic facility for use 
in a data processing system. 

5 

Typically, such a cryptographic facility may be required 
to provide a number of different services such as data 
encryption, key generation, and so on. Each service may 
have several different categories; for example, various 
10 types of cryptographic algorithm may be required. 

A list of available services may be stored in a table* 
For example, a list of available cryptographic algorithms 
may be held in a table referred to herein as a "supported 
15 algorithm list". 

In existing systems of this type, the introduction of a 
new service (e.g. a new cryptographic algorithm) presents 
considerable difficulties. For example, in the case of a 
20 new algorithm, it is necessary not only to introduce the 
new code for the algorithm, but also to modify the 
supported algorithm list to include a reference to the new 
algorithm. This in general involves a large amount of 
recompilation. * 
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The object of the present invention is to provide a way of 
simplifying the introduction of new services in such a 
system. 

5 Summary to the invention 

According to the invention there is provided a 
cryptographic facility for a data processing system, 
comprising: 

10 

means for defining a hierarchical structure of object 
classes defining cryptographic services, wherein each 
class can inherit functions and data from a base 
class in the hierarchy, 

15 

means for creating an instance of an object class, 
defining a cryptographic service , and for 
automatically registering that instance with a list 
of services supported by the system, 

20 

means for destroying an instance of an object class, 
defining a cryptographic service, and for 
automatically de-registering that instance with the 
list of services supported by the system, and 

25 

means for accessing the functions of an instance of 
an object class, defining a cryptographic service, 
through a base class of the object class in the 
hierarchy of object classes. 

30 

It will be seen that the problem of creating new services 
is facilitated by the hierarchical structure of the 
classes. Also, when a new instance of a class is created, 
it is automatically registered in the services list, so 
35 that it is not necessary for this to be done manually. 
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Brief description of the drawings 

Figure 1 is a block diagram of a data processing system 
including a cryptographic facility in accordance with the 
5 invention. 

Figure 2 is a block diagram showing the objects which 
interact with the cryptographic facility, 

10 Figure 3 is a schematic diagram illustrating notation used 
to describe object classes. 

Figure 4 is a schematic drawing showing object classes 
relating to cryptographic algorithms. 

15 

Figures 5 and 6 are flow charts showing constructor and 
destructor functions for a confidentiality algorithm 
object class. 

20 Description of an embodiment of the invention 

One cryptographic facility for a data processing system 
will now be described by way of example with reference to 
the accompanying drawings. 

25 

Referring to Figure 1, the system comprises a number of 
data processing units 10. The processing units can 
communicate with each other by way of communications 
facilities 12 in each processing unit. 

30 

Each processing unit includes a number of applications 14 
(i.e. applications programs). The applications can 
communicate with each other by way of the communications 
facility 12. 
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Each processing unit also includes a cryptographic support 
facility (CSF) 16 which provides cryptographic services to 
the applications. The CSF can communicate , by way of a 
CSF protocol handler 18, with a key distribution centre 
5 15, to obtain cryptographic keys. A security facility 19, 
is also provided to restrict access to some of the 
applications* 

The present system is implemented by means of a technique 
known as object oriented design, using the C++ programming 
10 language. For further details of object oriented design 
and C++, reference is made to "C++ Primer", S.B. Lippman, 
Addison Wesley (1989). 

Conventional design methods are based on the use of 
15 functional decomposition, where large problems are broken 
into smaller ones by concentrating on dividing the major 
steps which appear in the flow of control. The main 
limitation of designs produced by such methods is that 
they are not particularly good at coping with change, 
20 which often accounts for the majority of a software 
system's life. 

The main distinction between Object-Oriented Design (00D) 
and conventional design is that it is object-oriented and 
25 to process-oriented. 

Central to 00D is the concept of an 'object'. An object 
embodies an abstraction of information which is meaningful 
to its clients. It has the following properties: 

30 

a) An object has state encompassing all of the (usually 
static) properties and the current (usually dynamic) 
values of each of these properties. 

b) An object has behaviour defined by the 'services' it 
provides to its clients (other objects or * programs ) . 
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The terms 'operator' or method' are sometimes used instead 
of 'service'. Clients do not generally directly access 
the data in an object , they send 'messages' to the object 
requesting services to be carried out to access or 
5 manipulate the actual data in the object. The terms 
'request' is sometimes used instead of 'message'. A 
service may be classified as: 



10 



15 



20 



Modifier 
Selector 

Iterator 

Constructor 

Destructor 



alters the state of an object; 
accesses the state of an object without 
modifying it; 

permits the parts of an object to be 
visited; 

creates an object initialising its 
state; 

destroys the object freeing its state. 



In this way, objects provide information-hiding by data 
encapsulation. By avoiding direct client access to the 
data, one can guarantee certain integrity constraints of 
the object. It is also possible to change the object 
implementation without affecting the clients, unless there 
is a change in the nature of the services provided. 



25 

c) An object has identity and is denoted by a name. To 
make a request, a client identifies the object which 
is to perform the service and names the request. 
Requests may take arguments (including references to 
30 other objects) and the service may return one or more 

results. 



d) An object is an instance of some class. A class 

contains a common structure and a common behaviour 
applicable to all instances of the class. Classes 
can be derived from other classes (inheritance). 
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Ref erring now to Figure 2, this is a schematic diagram 
showing the CSF and the other objects within the system, 
with which the CSF interacts. 

5 The CSF uses a supported algorithm list 20. This contains 
a set of pointers to all the cryptographic algorithms 22 
that are currently available to the CSF. 

The CSF is used by a user 24 , which is typically one of 
10 the applications programs 14 (Figure 1). When the user 
requires to use the cryptographic facility, (e.g. to 
encrypt an item of data), it sends a message to the CSF, 
requesting it to perform the desired cryptographic 
operation . 

15 

It can be seen that the CSF thus provides a simple 
interface for cryptographic operations, such that the user 
does not need to be concerned with details of the 
algorithm, the choice of key, etc. 

20 

Each of the objects shown in Figure 2 is implemented by 
creating a specific instance of a particular object class. 
For example, a cryptographic algorithm is implemented by 
creating an instance of an object called "cryptographic 
25 -algorithm" . 

These cryptographic algorithm object classes are arranged 
in a hierarchical structure, as will now be described. 

30 Referring to Figure 3, this shows the notation used in 
this specification to describe the object classes and 
their hierarchical structure. 

As shown in Figure 3, each object class has a class name, 
35 and consists of a number of data members and member 

functions (using C++ terminology). Bach class may have a 
pointer to a base class, ie. to its parent class within 
the hierarchical structure. , 



-7- 



Data members that are inherited from the base class are 
denoted by broken lines, uninitialised data members are 
denoted by continuous lines, and initialised data members 
are denoted by bold continuous lines. Similarly, 
5 inherited member functions are denoted by broken lines, 
pure virtual member functions (see below) by continuous 
lines, and member functions in general by bold continuous 
lines. 

10 A pure virtual function is a function for which the 
interface is defined in a base class and its 
implementation is provided by a derived class. 

Two special operations supported by all classes are the 
15 'constructor' used to create and initialise an 

instantiation of the class, and the 'destructor' used to 
delete an instantiation of the class. 

In C++, a constructor and destructor are automatically 
20 generated by the compiler. The writer of a class may 
provide code for a constructor which is to be executed 
once the compiler-generated code has created the object 
and initialised the data members and the base classes of 
the object (base classes are initialised before derived 
25 classes). The writer may also provide initialisation lists 
which are used to initialise data members and base 
classes. In C++, a constructor takes the name of the 
class, for example (using the notation <class name>:: 
<f unction name> to represent the name of a function) 
Shift_Register_Generator: :Shift_Register_Generator is a 
class constructor. 

A class may also contain code for a destructor which is 
executed before compiler-generated code has deleted the 
35 object. In C++, a destructor is the name of the class 
prefixed by a '-', for example 

Shift_Register_ Generator^: :~Shif t_Register_Generator is a 
class destructor. , 
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Ref erring now to Figure 4, this shows how, in this 
particular example, cryptographic algorithms are 
implemented using a hierarchical structure of object 
classes. 

5 

The highest level of the hierarchy is an object class 
called "cryptographic algorithm". This class contains a 
number of data members and member functions as shown. 

10 The function "cryptographic-algorithm" is a constructor 
function which is used to create new instances of the 
class. Similarly, the function "~ cryptographic- 
algorithm" is a destructor function which is used to 
destroy instances of the class that are no longer 

15 required. 

The next level of the hierarchy consists of a number of 
sub-classes, representing the main categories of 
cryptographic algorithm provided by the CSF: 
20 confidentiality algorithms, integrity algorithms, and one- 
way functions. (Other sub-classes may also be provided) 
These categories provide generic interfaces for functions 
common to the category. 

25 Object classes for two specific algorithms ("Ipacrypt 5" 
and "Ipacrypt 50") are derived from the classes shown in 
Figure 4. It is possible for object classes to have 
multiple inheritance characteristics: for example, in this 
case, Ipacrypt 50 is derived front two of the main sub- 

30 classes. 



Referring now to Figure 5, this is a flow chart showing 
the constructor function for the confidentiality-algorithm 
object class (Fig. 4). 
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As shown the first action of this constructor function is 
to pass the parameters of the function to the constructor 
function of the base class ( "cryptographic-algorithm" ) . 
This will then, in turn, initialise the values for the 
5 various members that are inherited from the base class. 

The constructor function then sets the data member that 
indicates that the usage of the algorithm in question is 
for confidentiality. 

10 

Finally, the constructor function tests whether the 
inherited pointer to the supported algorithm list object 
is null. If it is non-null, the algorithm in question is 
registered with the supported algorithm list as being 
15 derived from the confidentiality algorithm sub-class. 

Referring to Figure 6, this is a flow chart, showing the 
destructor function for the confidentiality - algorithm 
object class. It can be seen that this automatically 
20 de-registers the algorithm. 

The constructor and destructor functions for the other 
main sub-classes act in a similar manner. 

25 As shown in figure 5, Ipacrypt 50 is derived from the 

classes confidentiality algorithm and integrity algorithm. 
Thus when an object of this algorithm is created, the 
constructor of the confidentiality algorithm class will 
register this object with the supported algorithm list as 

30 a confidentiality algorithm, and the constructor of the 
integrity algorithm class will also register this object 
with the supported algorithm list as an integrity 
algorithm. 

Note that the supported algorithm list only needs to know 
35 the identity of the algorithm being registered and from 

which of the main sub-classes it is derived from, it need 
have no knowledge about the actual class of the algorithm, 
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The CSF will call upon the supported algorithm list 
providing an algorithm identity and requesting a pointer 
to one of the main sub-classes of an object of that 
algorithm. For example, the CSF could request a pointer 
5 to the confidentiality algorithm class component of an 
Ipacrypt 50 object. The CSF can then invoke those 
functions of the object which are inherited from the sub- 
class (e.g. ' encipher ' ) . 

10 Installing a new algorithm involves linking in the module 
containing the class of the new algorithm which is derived 
from one or more of the main sub-classes, and creating an 
object of this class by invoking its constructor. The 
algorithm will then automatically register itself with the 
supported algorithm list for use by the CSF. 
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CLAIMS 

1. A cryptographic facility for a data processing 
system, comprising: 

means for defining a hierarchical structure of object 
classes defining cryptographic services, wherein each 
class can inherit functions and data from a base 
class in the hierarchy, 

means for creating an instance of an object class, 
defining a cryptographic service, and for 
automatically registering that instance with a list 
of services supported by the system, 

means for destroying an instance of an object class, 
defining a cryptographic service, and for 
automatically de-registering that instance with the 
list of services supported by the system, and 

means for accessing the functions of an instance of 
an object class, defining a cryptographic service, 
through a base class of the object class in the 
hierarchy of object classes. 

2. A cryptographic facility for a data processing system 
substantially as hereinbefore described with 
reference to the accompanying drawings. 
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